sciencewikiaorg_ru-20200216-history
SSL
SSL ( — уровень защищённых сокетов) — криптографический протокол, который обеспечивает безопасность связи . Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко используются для обмена мгновенными сообщениями и передачи голоса через IP (( - VoIP), в таких приложениях, как электронная почта, Интернет-факс и др. SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. Впоследствии, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS. Описание Протокол SSL позволяет общаться клиенту с сервером в сети, предотвращая перехват или фальсификацию. Так как протоколы могут работать либо без SSL либо поверх SSL, то для клиента необходимо указать серверу, хочет ли он установить соединение SSL или нет. Есть две возможности сделать это. Одним из вариантов является использование различных номеров портов для соединения SSL (например, порт 443 для HTTPS). Другой заключается в использовании регулярного номера порта, сервер установит соединение с клиентом, используя протокол конкретного механизма (например, STARTTLS для почты и новостных протоколов). После того как клиент и сервер решили использовать SSL, они ведут переговоры, отслеживая состояние соединения с помощью процедуры рукопожатия . Во время этого рукопожатия клиент и сервер соглашаются на различные параметры, используемые для установки безопасного соединения. После завершения процедуры рукопожатия начинается защищенное соединение. Клиент и сервер используют сеансовые ключи для шифрования и расшифрования данных, которые они посылают друг другу. Это нормальный алгоритм работы по защищенному каналу. В любое время, в связи с внутренним или внешним раздражителем (автоматическое вмешательство или вмешательство пользователя), любая из сторон может пересмотреть сеанс связи. В этом случае, весь процесс повторяется. SSL работает модульным способом. В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то полная длина заголовка равна двум байтам, иначе - длина заголовка равна трём байтам.Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка: RecLength = ((byte[ 0 ] & 0x7F) << 8) | byte[ 1 ]; Здесь byte0 и byte1 — первый и второй полученные байты. Длина записи 3-байтового заголовка: RecLength = ((byte[ 0 ] & 0x3F) << 8) | byte[ 1 ]; Escape = (byte[ 0 ] & 0x40) != 0; Padding = byte[ 2 ]; Здесь Padding определяет число байтов, добавленных отправителем к исходному тексту, для того, чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра. Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных и шифрует всё это. Причем не важно содержание заполнителя. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding. В свою очередь получатель записи расшифровывает все поля данных и получает полную исходную информацию. Затем производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент: * MAC_DataMac_Size — (Message Authentication Code) — код аутентификации сообщения * Padding_DataPadding — данные заполнителя * Actual_DataN — реальные данные Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data: MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number); Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счётчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32-битовый код, передаваемый хэш-функции. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка — 16383 байтов. История и развитие SSL 1.0, 2.0 и 3.0 Протокол SSL был изначально разработан компанией Netscape Communications. Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL версии 3.0. SSL версии 3.0, выпущенная в 1996 году, послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF), который впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети. TLS 1.0 TLS 1.0 впервые был определен в RFC 2246 в январе 1999 года в качестве обновления версии SSL 3.0. Как указано в RFC "различия между этим протоколом и SSL 3.0 не критичны, но они значительны для появления несовместимости при взаимодействии TLS 1.0 и SSL 3.0". TLS 1.0 действительно включает средства, с помощью которых реализация подключения TLS к SSL 3.0, ослабит безопасность. TLS 1.1 TLS 1.1 презентовали в RFC 4346 в апреле 2006 года. Это было обновление TLS версии 1.0 Значительные изменения в этой версии включают в себя: * Добавлена защита от атак, использующих режим сцепления блоков шифротекста (Cipher Block Chaining). ** Неявный Вектор инициализации (IV) был заменен на явный IV. ** Было проведено изменение в обработке ошибок. * Введена поддержка IANA регистрации параметров. TLS 1.2 TLS 1.2 был анонсирован в RFC 5246 в августе 2008 года. Он основан на ранее предложенной версии TLS 1.1. Применение При проектировании приложений SSL реализуется поверх любого другого протокола транспортного уровня, таких как HTTP, FTP, SMTP, NNTP и XMPP. Исторически SSL был использован в первую очередь с надежными транспортными протоколами, такими как Transmission Control Protocol (TCP). Тем не менее, он также был реализован с датаграммным транспортным протоколом, таким как User Datagram Protocol (UDP) и Datagram Control Protocol (DCCP), использование которого было стандартизировано, что привело к использованию термина Datagram Transport Layer Security (DTLS). Вебсайты Частое использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443. Браузеры По состоянию на 2013 г. все основные веб-браузеры, поддерживающие SSL/TLS: Уточнения: * Google Chrome поддерживает TLS 1.0 и TLS 1.1, начиная с версии 22 (она была добавлена, но потом был откат до 21 версии). TLS 1.2 не поддерживается. * В OS X спользуется TLS предоставляемые от Network Security Services (NSS). По состоянию на март 2013 года, NSS 3.14.3 поддерживает TLS 1.0 и 1.1, но не версию 1.2. * Firefox поддерживает только TLS 1.0, несмотря на поддержку NSS TLS 1.1. * IE использует реализацию TLS от операционной системы Microsoft Windows предоставляемых SChannel. TLS 1.1 и 1.2 по умолчанию отключены. * Opera 10 имеет поддержку TLS 1.2. Предыдущие версии поддерживали TLS 1.0 и 1.1. TLS 1.1 и 1.2 по умолчанию отключены (за исключением версии 9"Changelog for Opera 9.0 for Windows" at Opera.com ). * Safari использует реализацию операционной системы Mac OS X, Windows (XP, Vista, 7) Safari 5 является последней версией дотупной для Windows. * Mobile Safari и программное обеспечение сторонних производителей с использованием библиотечных систем UIWebView поддерживают TLS 1.2 как и iOS 5.0. , section "HTTPS (SSL/TLS)" Использование и реализация Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте. Наиболее распространенная реализация SSL — криптографический пакет с открытым исходным кодом OpenSSL, основанный на SSLeay, написанной Эриком Янгом. Последняя версия OpenSSL поддерживает SSLv3. Пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Библиотека используется, например, модулем SSL в распространенном HTTP-сервере Apache. Аутентификация и обмен ключами SSL поддерживает 3 типа аутентификации: * аутентификация обеих сторон (клиент — сервер), * аутентификация сервера с неаутентифицированным клиентом, * полная анонимность. Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret). Анонимный обмен ключами Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret). Аутентификация и обмен ключами при использовании RSA В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура включает текущее значение сообщения Client_Hello.random, таким образом старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера. Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия включают сертификат сервера, который ставит в соответствие сигнатуре сервера, сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия. Аутентификация и обмен ключами при использовании Diffie-Hellman В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру, для уверенности, что параметры принадлежат серверу. Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требуемую для того, чтобы завершить обмен ключами. Заметим, что в этом случае клиент и сервер должны будут сгенерировать те же Diffie-Hellman результаты (pre_master_secret), каждый раз, когда они устанавливают соединение. Для того чтобы предотвратить остановку секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, на сколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами. Протокол записи Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента. Существует четыре протокола записи: # Протокол рукопожатия (handshake protocol); # Протокол тревоги (alert protocol); # Протокол изменения шифра (the change cipher spec protocol); # Протокол приложения (application data protocol); Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол, созданный для использования совместно с SSL, должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик. Протокол рукопожатия SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения: # Клиент посылает серверу номер версии SSL клиента, зашифрованные параметры, специфичные данные для сеанса и другую информацию, которая нужна серверу, чтобы общаться с клиентом, используя SSL. # Сервер посылает клиенту номер версии SSL сервера, зашифрованные параметры, специфичные данные для сеанса и другую информацию,которая нужна серверу, чтобы общаться с клиентом по протоколу SSL. Сервер также посылает свой сертификат, который требует проверки подлинности клиента. После идентификации сервер запрашивает сертификат клиента. # Клиент использует информацию, переданную сервером для проверки подлинности. Если сервер не может быть проверен, пользователь получает предупреждение о проблеме и о том, что шифрование и аутентификация соединения не может быть установлена. Если сервер успешно прошел проверку, то клиент переходит к следующему шагу. # Используя все данные, полученные до сих пор от процедуры рукопожатие, клиент (в сотрудничестве с сервером) создает предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера , отправленного на 2-ом шаге), а затем отправляет его на сервер. # Если сервер запросил аутентификацию клиента (необязательный шаг рукопожатия), клиент также подписывает еще один кусок данных, который является уникальным для этого рукопожатия и известным как для клиента, так и сервера. В этом случае, клиент отправляет все подписанные данные и собственный сертификат клиента на сервер вместе с предварительно зашифрованным секретом. # Сервер пытается аутентифицировать клиента. Если клиент не может пройти проверку подлинности, сеанс заканчивается. Если клиент может быть успешно аутентифицирован, сервер использует свой закрытый ключ для расшифровки предварительного секрета, а затем выполняет ряд шагов (которые клиент также выполняет), чтобы создать главный секрет. # И клиент, и сервер используют секрет для генерации ключей сеансов, которые являются симметричными ключами, использующиеся для шифрования и расшифрования информации, которой обмениваются во время SSL сессии. Происходит проверка целостности (то есть, для обнаружения любых изменений в данных между временем когда он был послан, и временем его получения на SSL-соединении). # Клиент посылает сообщение серверу, информируя его, что будущие сообщения от клиента будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена. # И в заключение, сервер посылает сообщение клиенту, информируя его, что будущие сообщения от сервера будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена. На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается. Протокол изменения параметров шифрования Протокол изменения параметров шифрования существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1. struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; Сообщение изменения шифра посылается клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение "finished". Протокол тревоги Один из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения. Протокол приложения Сообщение приложения данных работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи. Безопасность Существует ряд атак, которые могут быть предприняты против протокола SSL. Однако SSL устойчив к этим атакам, при условии, что пользователь использует только доверенные сервера для обработки информации. SSL 2.0 уязвима в некоторых ситуациях: # Идентичные криптографические ключи используются для аутентификации и шифрования сообщений, # SSL 2.0 имеет слабую MAC конструкцию, которая использует MD5 хэш-функцию с секретом префикса, что делает его уязвимым для атак, # SSL 2.0 не имеет никакой защиты для протокола рукопожатия, то есть атака типа злоумышленник посередине (man-in-the-middle) могут остаться незамеченными, # SSL 2.0 использует TCP закрытое соединенние, чтобы указать конец данных. Это означает что возможна следующая атака: злоумышленник просто подделывает TCP FIN, оставив получателя без сообщения о конце передачи данных (в SSL 3.0 эту ошибку исправили) # SSL 2.0 предполагает наличие единой службы поддержки и фиксированного домена, что идет вразрез со стандартной функцией виртуального хостинга на веб-серверах. SSL 2.0 по умолчанию отключена в браузерах, начиная с Internet Explorer 7, Mozilla Firefox 2, Opera 9.5,"Opera 9.5 for Windows Changelog" at Opera.com: "Disabled SSL v2 and weak ciphers." и Safari. TLS имеет целый ряд мер безопасности. С точки зрения безопасности, SSL 3.0 следует считать менее надежным, чем TLS 1.0. В SSL 3.0 есть слабые моменты. К примеру, половина мастер-ключа (master key), которая устанавливается, полностью зависит от хэш-функции MD5, которая не является устойчивой к столкновениям и, следовательно, не считается безопасной. Атака отклика Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 2^{64} кодов nonce, чтобы получить вероятность угадывания 50 %. Но 2^{64} достаточно большое число, что делает эти атаки бессмысленными. Атака протокола рукопожатия Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес. Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения "finished". Без знания секрета злоумышленник не сможет исправить сообщение "finished", поэтому атака может быть обнаружена. Взлом SSL-соединений агентами ФБР с помощью систем Carnivore и NarusInsight Наиболее известный инцидент по массовому взлому информации, защищенной протоколами SSL, был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T, который установил данные комплексы для взлома криптографически защищенной информации. Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей, технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установлены в самом ЦОД, где находились сервера, ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные, поступившие по SSL, были расшифрованы самим сервером, их принявшим от внешних пользователей. Тем не менее, указанный инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернете, так как спецслужбы могут установить системы прослушивания, такие как NarusInsight или СОРМ-2, в ЦОД. Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом. BEAST атака 23 сентября 2011 года тайские исследователи Дуонг и Джулиано Риццо продемонстрировали "доказательство концепции" под названием Beast, ("Browser Exploit Against SSL/TLS") используя Java апплет, продемонстрировали уязвимость в TLS 1.0. Практически, ранее эту уязвимость, которая первоначально была обнаружена Phillip Rogaway в 2002 году, никто не мог продемонстрировать. Уязвимость TLS 1.1 была зафиксирована в 2006 году. RC4 атака Несмотря на существующие атаки на RC4, шифр на основе RC4 в SSL и TLS считали безопасным. В 2011 RC4 был рекомендован как средство защиты от Beast атаки. Однако в 2013 году было совершено нападение по сценарию, предложенному Алфардом, Бернштейном, Патерсоном, Поттерингом и Шхултдом, которые использовали новые статистические погрешности в RC4 ключе. Раскрытие шифров Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA. Из-за того, что большинство SSL-сайтов не используют алгоритмы со свойством perfect forward secrecy (PFS)SSL: Intercepted today, decrypted tomorrow, злоумышленник записавший зашифрованные сессии, сможет их прочитать после того как получит приватный ключ RSA. Злоумышленник посередине Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL , так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации . Атака будет успешной, если: * Сервер не имеет подписанного сертификата. * Клиент не проверяет сертификат сервера. * Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или сообщение о несовпадении сертификата с кэшированным . Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft. В данном случае "злоумышленник" находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS. Наиболее спорным становится вопрос информированности пользователя о возможности перехвата данных, т.к. в случае подмены корневого сертификата никаких сообщений безопасности выводиться не будет и пользователь будет ожидать конфиденциальности передаваемых данных. Кроме того, при использовании Forefront TMG в качестве SSL-прокси возникает возможность проведения второй MitM-атаки на стороне интернета, т.к. оригинальный сертификат не будет передан пользователю, а Forefront TMG может быть настроен на прием и последующую подмену самоподписанных или отозванных сертификатов. Для защиты от подобной атаки необходимо полностью запретить работу с веб-серверами, чьи сертификаты содержат какие-либо ошибки, что безусловно приведет к невозможности работы по протоколу HTTPS со множеством сайтов. Обработка ошибок в протоколе SSL В протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения. Протокол SSL определяет следующие ошибки: # Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента). # No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима. # Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента). # No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима. Алгоритмы, использующиеся в SSL * Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK . * Для аутентификации: RSA, DSA, ECDSA. . * Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES, Camellia. * Для хеш-функций: SHA, MD5, MD4 и MD2. См. также * TLS * JSSE * OpenSSL * SSH * tcpcrypt Примечания Ссылки * Mozilla.org — введение в SSL протокол Литература ; Книги * |заглавие = Discovery and Exploitation of New Biases in RC4 |издание = 1-st |издательство = Springer Berlin Heidelberg |год = 2011 |том = 1 |страницы = 24 |страниц = 91 |isbn = 978-3-642-19573-0 }} * |заглавие = COmputer Security and Industrial Cryptography |издание = 3-t |издательство = Leuven—Heverlee, Belgium |год = 2002 |том = 1 |страницы = 253–265 |страниц = 287 |isbn = 0167-4048 }} * |заглавие = Network Security with OpenSSL |издание = 1-st |издательство = O'Reilly Media, USA |год = June 15, 2002 |том = 1 |страницы = |страниц = 386 pages |isbn = 978-0596002701 }} * |заглавие = SSL and TLS: Designing and Building Secure Systems |издание = 1-st |издательство = Addison-Wesley Professional |год = October 27, 2000 |том = 1 |страницы = |страниц = 528 pages |isbn = 978-0201615982 }} * |заглавие = SSL & TLS Essentials: Securing the Web |издание = 1-st |издательство = Wiley |год = February 11, 2000 |том = 1 |страницы = |страниц = 224 pages |isbn = 978-0471383543 }} ; Статьи * * * * * Категория:Сетевые протоколы Категория:Криптография